A web service is a software vehicle that accepts requests from a client to perform operations. At this time, these requests are typically in the form of Extensible Markup Language (XML). Although XML is used as an example, other forms of invocation are also possible. In most cases, a web service returns a response after processing the request. Web services typically operate independently of a specific computer language, platform, or location. Therefore, a client can contact a web service that is written in a different programming language, which is running on a different platform, and is located across a network.
Because web services can contact each other to request the execution of operations, they serve as building blocks for distributed systems. Distributed systems composed of web services may span multiple machines, a corporate intranet, or the Internet. Combining web services from a base environment with web services outside the base environment, such as those operated by partners or suppliers, can enable complex applications to perform sophisticated business activities. Accompanying this complexity, however, is an increased difficulty in detecting and resolving errors in the large number of messages used to support such business activities.
A common message type used to transact web services is based on SOAP (Simple Object Access Protocol). SOAP is a protocol specification that defines a uniform way of passing XML-encoded data. SOAP also defines a way to perform remote procedure calls using HTTP (or another transport protocol) as the underlying communication protocol. A client sends a SOAP request message to the web service, and receives a SOAP response message in return. Using SOAP, the service requestor and the service provider can communicate as long as they agree on a common transport protocol (such as HTTP) and the message's SOAP definition. This increases the opportunities for reuse, as the service places essentially no constraints on the platform, language, or location of its clients. But even with the flexibility of using such messages, monitoring, managing, and controlling web service systems and transactions can be difficult.
In particular, any one of the large number of web service messages used to transact web services can include an error that is difficult both to detect and to resolve. Anomalies in web services transactions are generally more difficult to detect unless viewed in a context, such as over a set of messages. And without a mechanism to detect such errors, deficient messages can lead to failed business transactions, lower customer satisfaction, lost orders, and lost revenue. Typically, the keys to resolving such errors lie within the messages themselves. That is, a group of messages required to transact a specific web service generally will contain information that can be used to rehabilitate a defective message. But at present, there are no satisfactory techniques for correlating that information so that it can be harvested for real-time error correction or message modification.
In view of the foregoing, it would be desirable to provide a mechanism for enhancing the functionality of existing web services. Ideally, the technique would provide enhanced functionality to effectively identify and relate web service messages so as to detect, report and correct message errors before deficient messages are sent. By correlating web service messages, self-healing web service transactions can be realized.